1st workshop

Introduction

Since 2008, ENISA is executing a Multiannual Thematic Program with the ultimate objective to collectively evaluate and improve the resiliency of public eCommunications in Europe. The MTP is comprised of four distinct phases. The first step performed was an analysis on how national authorities implement current regulatory measures, assessing how network and service providers of public Communication Networks ensure availability and integrity of their networks and services, and evaluating whether existing technologies satisfy the needs and requirements of these providers.

The preliminary results of the analysis as well as possible directions in terms of recommendations that the Agency will follow in the second phase of the MTP were presented at the workshop “Improving Resilience in European e-Communication Networks”, organised by the Agency on November 12th-13th 2008, in Brussels. Focusing in technologies, during the workshop, the need to increase security and availability of DNS using a form of a Key Infrastructure was highlighted among the priorities for Europe. Concerning such Key Infrastructure architecture the consensus by the workshop participants was, that:

• An assessment of the possible deployment alternatives should be carried out.
• The deployment as distributed authority should be considered.
• There is a need for the creation of tools available to administrators as well as for users.

Targets of the first workshop

The main targets of the workshop consisted of:

• Update participants of the deployment status of DNSSEC. Signing of TLDs and root. Experiences from  registries, registrars and registrants that have implemented DNSSEC.
• Identify gaps.
  

• Investigate other options or parallel actions for improving  DNS’s resilience.
• Explore possible actions that ENISA can take up

• Identify which of these tasks can be performed in a working group.
• Cooperation of ENISA with other organisations or alliances sharing the same goals

As main stakeholders, the following groups have been identified:

• Enterprises that manage their own network, DNS, and public internet services,
• Hosting companies and DNS providers,
• Registrars,
• Registries.

The workshop gave the opportunity to 18 experts and stakeholders in the area to meet, exchange ideas and agree upon a clearly defined set of actions that ENISA will pursuit in the course of the abovementioned MTP.

Experiences from deploying DNSSEC

A demonstration was provided during the workshop displaying the results of a cache poisoning attack on systems not deploying DNSSEC. The cache poisoning attack was performed on e-government service where the users were redirected to a malicious server, the use of SSL was disabled and eventually access to user’s credentials was gained by the attacker.

.SE is the first TLD registry that commercially deployed DNSSEC back in 2007 with manual administration of the all the processes. Since then, they automated the administration and they are providing DNSSEC as a free service from 2009. A new business model will be implemented by .SE in March 2009 when they will use the EPP protocol for communication with the registrars. A new system for key management and zone signing is expected to be introduced in fall 2009.

.SE worked with all the stakeholders in Sweden to promote the deployment of DNSSEC. Eleven registrars have deployed DNSSEC and provide services to registrants. The majority of the large service providers are validating signatures in their recursive resolvers. These recursive resolvers are then used by the end user’s stub resolvers.

In .SE more than 1500 zones are signed. This roughly represents the 0.2% of all .SE zones. A significant rise can identified on the number of signed zones in .SE registry when the changed their charging policy, early 2009.

.SE’s mandate on deploying DNSSEC comes from its foundation’s statutes where they are obliged to provide secure DNS services. .SE is audited be the Swedish Post and Telecom Agency (PTS).

The deployment of DNSSEC in .CZ registry was the main project they run in 2008 because of the importance of the technology in improving the security of DNS. Their first action was meeting with registrars and explaining the principles of DNSSEC, exploring Sweden’s experiences and presenting their solution. The full deployment of DNSSEC came in October 2008.

Their solution includes transfer of the key material with the EPP protocol from the registrar and checking that the same key exists in the delegated zone. They support sharing between domains and multiple keys for easy key rollover. Registration of the KeySet is free. They marketed the deployment of the technology by publishing articles in newspapers, technical portals and provided courses for DNS administrators. They targeted at the same time content providers and domain registrants towards signing their zones, ISPs and recursive DNS administrators to enable validation on nameservers, governmental agencies and banks.

The deployment didn’t come without cost. There was a huge increase in zone size, from 40MB to 180MB which led to memory and bandwidth problems that were solved by reusing signatures.

After 4 months of deployment they have 6 out of 32 registrants supporting and offering DNSSEC registrations and almost 500 domains signed. This is roughly 0.1% of al .CZ domains. They will continue promoting DNSSEC on the same track and also try to lower the time interval between zone updates by implementing incremental zone transfers.

.BG deployed DNSSEC in production in 2007 and provided DNSSEC tools for registrars in 2008. The DNSSEC delegation service is provided as a basic service fully integrated into Registry system. To authenticate the users of the registry they use digital signature certificates. In contrast to the other registries they require the signatures of the keys to be transferred from the registrant to the registry and perform only syntax tests. They provide tools for zone verification thus they only display warnings when the keys in the zone and the hashes provided for delegation do not match.

Over 250 DNSSEC delegated zones exist in .BG as of December 2008 which is about 1% of all .BG zones. There was a slow start in DNSSEC deployment by ISPs and DNS service providers due to lack of competence and fear of increased workload. Effort is given in deploying DNSSEC in the public sector and governmental agencies.

RIPE, the Regional Internet Registry for Europe, Central Asia and the Middle East serves as registry for 51 reverse DNS zones where they have deployed DNSSEC. These zones are special in the sense that they can be easily enumerated. Thus, using NSEC3 protocol instead of NSEC to help keep the zone private is clearly not necessary. The update of the DS delegation records are following the some authentication methods that exist for maintaining the RIPE database. These include MD5 passwords and PGP keys.

The signed delegations out of those zones are reaching at 0.05%. For the future, RIPE is looking to have secure key storage & backups in an easier manner, use Hardware Signing Modules, fully automate key rollovers and emergency procedures and automate uploading of DS to the parent.

IKS GmbH, a service provider company, provides, among other things, DNS signing and validation services to its clients though rather innovative ways. To solve the problems they identified in validation, mainly the update of trust anchors in the configuration of the recursive resolver, they are providing a DNSSEC Lookaside Validation service and a signed root, based on IANA data, to their customers. To sign the zones of their customers without the need to update any of their software or DNS appliances, they have developed and provide remote signing tools using a hidden primary DNS server. IKS is also running a survey of worldwide DNSSEC deployment . The results of the survey are published every month.

Threats on DNS and mitigation measures

During the workshop, a brief enumeration of the threats to DNS was provided. Further to the ID guessing and resulting cache poisoning attacks, important open issues remain:

• The outdated information that can remain stale in the DNS, with TTL values taht can reach up-to 68 years. Moreover, some DNS caching-only servers, ignore the TTL value which leads to serving old data.
• Domain Name Hijacking. By using forged registration credentials, an attacker can trick the registrar into changing domain settings or transfer the domain to another registrar.
• DNS “Fast Flux”, a technique used by botnets to hide phishing and malware delivery sites behind an ever-changing network of compromised hosts acting as proxies.
• Typosquatting which is an attack that relies on users making mistakes such as typographical errors when typing a website address into a browser.
  

DNSSEC is an extension to DNS that provides origin authenticity, data integrity, and secure denial of existence of the DNS data, by using public-key cryptography. When deployed, mitigates significantly the ID guessing and cache poisoning risks on the resilience of DNS. Alternative security architectures to improve DNS’s resilience include:

• Securing the connections used by DNS.
• Use of additional defences.
• Development and testing of another Signing protocol.

TSIG is a protocol that can be used to protect the paths between DNS entities. It should be used to protect the dada exchanges between Primary and Secondary name server, the zone transfers. It should also be used to protect the communication of a stub resolver with the recursive resolver in an administrative domain. Due to its shared secret architecture, it doesn’t scale well to protect the communication between recursive name server and authoritative servers.

Opportunistic encryption could be used to encrypt the communication between DNS entities. This kind of encryption can be easily applied but it does not provide authentication. Another approach would be to use TCP connections instead of UDP in the communication between recursive resolvers and authoritative servers. TCP is more resilient than UDP as it establishes connections though a three-way handshaking procedure. Tracking the states of such connections in a high volume server would increase its load significantly.

Anycasting is used to bring the authoritative name servers closer to the recursive resolvers significantly lowering the response time and the window of time the attackers have in order to achieve an attack. While this is used extensively by the TLDs it is not scalable to registrant name servers because of costs and the strain it puts in the routing infrastructure.

The use of Intrusion Detection technology to protect the recursive resolvers is provided by some vendors. This is part of the additional defences introduced to mitigate the cache poisoning attacks and has to be deployed in every single recursive resolver. Other additional defences include the EDNS Option for performing a data PING and the use of Bit 0x20 in DNS Labels to Improve Transaction Identity by adding bits of randomness in UDP communication. Both of those two additional defences require changes in the DNS protocol that have to be developed, tested and adapted by all the DNS authoritative servers and recursive resolvers.

Another signing protocol has been recently introduced. It is called DNSCurve and it uses elliptic cryptography. One of its main differences from DNSSEC is that the exchanged data are encrypted and thus authenticated during the communication between the recursive resolver and the authoritative server. This protocol is in a development phase.

While there are several security architectures that could be used to protect the DNS, there is a basic duality between their use and signing the data itself. Signing the data and the use of the above mentioned security architectures should be seen as complimentary actions. DNSSEC is being developed for almost 20 years, it is deployed by several TLDs and there have no better, easier or cheaper alternatives been identified.

Challenges to the deployment of DNSSEC and improvement of DNS’s resilience

During 2008, ENISA took stock on the deployment of three technologies and their effect on improving public eCommunication resilience. One of the tree technologies investigated was DNSSEC. The interviewed operators and service providers identified several barriers in the deployment of the technology. These barriers are:

• Key management/signing complexity.
• Trust anchor management.
• Lack of Tools.
• Lack of User awareness.

A major obstacle to the widespread adoption of DNSSEC is the complexity of implementing it. While, technical document that explain the specifics of the protocol exist, documents that explain what consideration should be made before deploying DNSSEC are missing. Issues that should be addressed in such documents are among others, the communication between domain administrator and registry, procedure for stopping DNSSEC in a zone, timing in key changes, the procedure by which the key material is passed between DNS operator and the Registry and what happens during transfer of a domain name. Also, policy and practices documents do not exist as templates and are not well aligned between registries.

Trust anchor repositories and DLV services are essential for the deployment of DNSSEC before the signing of the DNS root. Even after that, some islands of DNSSEC will still remain as not all TLDs will deploy the technology. These TARs should follow a set of rules that they publish on their policy document. The means by which the policy is applied should also be documented in a practices document. Such template documents do not exist.

Furthermore, there is no package that one can install on a system, click the "start" button, and have DNSSEC running. Instead, there are a variety of tools, none of which on their own is a complete solution. To actually run a DNSSEC-enabled authoritative server requires writing custom scripts to link those tools together. Even then, aspects of DNSSEC management such as key management and use of hardware assistance (such as HSMs) have not been adequately addressed.

Tools are also missing for the deployment of DNSSEC by the registries. The registries that have deployed DNSSEC in production or test environments have developed their custom tools. This is an expensive and time consuming procedure and technical expertise is needed. The developed tools have to be evaluated and tested. Even so, tools for specific tasks as dynamic update of signed zones that will reduce the required effort in signing a zone and updating the secondary servers are missing.

End-users do not yet see immediate benefits of DNSSEC. They are not informed if a domain they are visiting is protected with DNSSEC. Such a display on a browser would increase the awareness of the users. Also documents that will educate the users on what DNSSEC can protect and what is not protected are missing. Such documents will help remove the fog on the protection offered by the technology. User awareness will also push towards the deployment of the technology.

The public sector needs to be activated in order to remove any obstacles. Having clauses in public tenders that address the resilience of networks and DNS will help in improving the overall resilience.

Actions in progress

There are several groups of stakeholders that are working to solve the problems that are barriers to the deployment of DNSSEC. There are also stakeholders working for the promotion of DNSSEC deployment. One such coalition of stakeholders is the “DNSSEC Industry Coalition”.
Concrete projects that are currently executed with the above-mentioned goals include:

• The DNS Operations Working Group of IETF is currently revisiting the RFC 4641 “DNSSEC Operational Practices”. This RFC discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This is a technical document with target audience the zone administrators deploying DNSSEC.
• The production of a set of templates based on RFC 3647 “Certificate Policy and Certification Practices Framework” that can be used by registries is a project taken up by .SE. These templates will provide guidance to the registries that want to deploy DNSSEC, transfer the experience gained by those already deployed it and align the policies and practices of the registries. As a result domain holders and zone operators will know the requirements opposed to them and how the registry implements its practices and controls.
• The DNS Extensions working group of IETF has adapted an Internet-Draft document that provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network. This draft addresses the issue that many commonly-used broadband routers (and similar devices) contain DNS proxies which are incompatible in various ways with current DNS standards, including DNSSEC.
• OpenDNSSEC project, which aims to produce software that will handle all the tasks need to deploy DNSSEC. Installed on a system, with a minimum amount of operator input, it will handle the signing of DNS records, including the regular re-signing needed during normal operations; handle the generation and management of keys, including key rollover; it will seamlessly integrate with external cryptographic hardware such as HSM’s (including USB tokens and smart cards); seamlessly integrate into an existing deployment scenario, without the necessity to overhaul the entire existing infrastructure. The OpenDNSSEC software will be applicable to a wide variety of DNS configurations, including organisations (such as TLDs) that manage few zones, each with a large number of records, organisations (such as ISPs) that manage a large number of zones, each with few records and organisations (such as companies managing their own zones) that have a single zone with relatively few records.
  

In the political level, US Department of Commerce’s National Telecommunications and Information Administration (NTIA), that are responsible in authorizing changes or modifications to the authoritative root zone file, issued a Notice of Inquiry seeking public comments regarding the deployment of DNSSEC into the Internet’s DNS infrastructure, including the authoritative root zone. The NOI and public comment received are available at the agency’s webpage. At the same time the EU High Level Group on Internet Governance (HLIG) organised a technical workshop to review the situation on DNSSEC in order to help inform policy makers regarding the relevant public policy questions.

Possible tasks that ENISA should take up

The workshop participants, during the round table discussions, proposed that ENISA should take up several actions in order to improve the resilience of DNS and thus promote the resilience of public eCommunications networks through Europe. These actions should foster the deployment of DNSSEC throughout EU member states.

A good practices guide for deploying DNSSEC should be developed. This guide should include the considerations that a recursive resolver operator that wants to validate DNS queries and a zone operator that wants to sign its zones should consider while proceeding in DNSSEC deployment. The guide will not duplicate the technical issues presented in RFC4641, it will rather complement it. Issues that should be considered are: the transition from a signed zone to an unsigned, change of registrar, the use of NSEC3 or NSEC, transfer of the key material to the registry, use of Trust Anchor Repositories, key rollover.

A document should be developed that advocates the use of the technology, clarify the assets secured by DNSSEC and identifies the remaining open issues. This document would be a high level document targeting domain holders and policy makers. A script for an interactive video with the same targets should also be produced.

As the use of Trusted Anchor Repositories is required before the full deployment of DNSSEC, a document describing what a user should expect from such a repository, how the key material is transferred and the identity of the owner of a domain is identified should be produced. Such a TAR policy and practices statement may follow the RFC 3647 “Certificate Policy and Certification Practices Framework” and the work performed in applying the same RFC on domain registries implementing DNSSEC.

In order to promote the deployment of DNSSEC throughout Europe a document that will encourage the public sector towards this direction should be produced. A stricter approach could be used for e-government services. This document should be promoted by ENISA and could be used as a basis to form a Communication of the European Commission to address the issue of deployment of DNSSEC. This document is foreseen in the third phase of the development of ENISA’s MTP for the improvement of the resilience of public eCommunications networks.

The formation of an expert group with the participants of the workshop was decided. The expert group will take up the task of delivering the documents described above. The work of the expert group will be finished by end of September 2009 for the first three deliverables. To facilitate this work, a caretaker and list of contributors for each task should be defined and two more meetings should be scheduled. ENISA will also host a mailing list and provide the resources for voice conferences.

With the feedback received for ENISA’s deliverable “Resilience Features of IPv6, DNSSEC and MPLS and Deployment Scenarios” it was proposed that a study should be made on "The costs of DNSSEC deployment". The study should cover all different areas from registrants, registrars, registries to name service providers and ISP's, regarding hardware, software and staff training. Another subject that could be included in this study is the operational experience from those that deployed DNSSEC. The study should be performed by an objective consulting company.

At last it was proposed to ENISA to “drive by example” and deploy DNSSEC in its zone. This will display the agency’s commitment in improving the resilience of public eCommunications networks and provide an example to other agencies and EU member states public sector.